Write down spoofed packet guarantees #1347

martinthomson · 2018-05-10T05:53:24Z

We agreed to this a while back, but never got around to putting the conclusions in the document. We've done some of the work by writing down the rules for use of CONNECTION_CLOSE and TLS alerts, and the related changes, but the basic principles never got articulated.

This attempts to outline what we do to authenticate packets that we receive.

Once the handshake is done, it's mostly simple: if the AEAD fails, drop it.
We have a small carve-out for some types of ICMP, with some strong limitations on what that information can be used for. @igorlord might expand the PMTU usage to cover DestUnreach, but these uses permit a very narrow range of actions.
We also have stateless reset, which is another snowflake.
The bulk of the text here concerns the handshake. I've covered the two mechanisms we tie into the use of connection IDs:
** Echoing the value (the only protection we have for Version Negotiation, for instance).
** The AEAD that uses the connection ID as input.

And then it explains that our only defense against an on-path attacker is to fail to establish a connection. I think that covers all the necessary points.

Closes #645.

@igorlord

We agreed to this a while back, but never got around to putting the conclusions in the document. We've done some of the work by writing down the rules for use of CONNECTION_CLOSE and TLS alerts, and the related changes, but the basic principles never got articulated. This attempts to outline what we do to authenticate packets that we receive. * Once the handshake is done, it's mostly simple: if the AEAD fails, drop it. * We have a small carve-out for some types of ICMP, with some strong limitations on what that information can be used for. @igorlord might expand the PMTU usage to cover DestUnreach, but these uses permit a very narrow range of actions. * We also have stateless reset, which is another snowflake. * The bulk of the text here concerns the handshake. I've covered the two mechanisms we tie into the use of connection IDs: ** Echoing the value (the only protection we have for Version Negotiation, for instance). ** The AEAD that uses the connection ID as input. And then it explains that our only defense against an on-path attacker is to fail to establish a connection. I think that covers all the necessary points. Closes #645.

janaiyengar · 2018-05-23T01:02:36Z

draft-ietf-quic-transport.md

+
+As an encrypted and authenticated transport QUIC provides a range of protections
+against denial of service.  Once the cryptographic handshake is complete, QUIC
+endpoints discard packets that are not authenticated, greatly limiting the


how about "most packets", since there clearly are unauthenticated packets that are accepted.

Sure. I was hoping that we could ultimately authenticate even those packets that don't have packet protection in some way. For instance, by ensuring that the ICMP unreachable includes bytes from a packet we sent. But maybe that's stretching the definition too far.

janaiyengar · 2018-05-23T01:05:18Z

draft-ietf-quic-transport.md

+
+The first mechanism used is the source and destination connection IDs, which are
+required to match those set by a peer.  Except for an Initial packet and
+stateless reset, an endpoint only accepts packets that include a destination


"Except for Initial and Stateless Reset packets"

janaiyengar · 2018-05-23T01:07:32Z

draft-ietf-quic-transport.md

+The destination connection ID in an Initial packet is selected by a client to be
+unpredictable, which serves an additional purpose.  The packets that carry the
+cryptographic handshake are protected with a key that is derived from the
+connection ID and salt specific to the QUIC version.  This allows endpoints to


s/the connection ID/this connection ID/

janaiyengar · 2018-05-23T01:09:39Z

draft-ietf-quic-transport.md

+use the same process for authenticating packets that they receive as they use
+after the cryptographic handshake completes.  Packets that cannot be
+authenticated are discarded.  Protecting packets in this fashion provides a
+strong assurance that the sender of the packet saw previous packets and


s/saw previous packets and understood them/saw the Initial packet and understood it/

janaiyengar · 2018-05-23T01:13:30Z

draft-ietf-quic-transport.md

+These protections are not intended to be effective against an attacker that is
+able to receive QUIC packets.  Such an attacker can potentially send packets
+that will be accepted by QUIC clients or servers.  This version of QUIC only
+attempts to detect this sort of attack.  Interference with the handshake is


s/only attempts to detect/attempts to only detect/

I've reworded this to be a little clearer (I hope). I think that it is important to say that we don't expect endpoints to do anything other than fail when an attacker tampers with the handshake. I realize that the lead-in to this paragraph didn't scope that properly though. Have another look.

janaiyengar · 2018-05-23T01:18:18Z

draft-ietf-quic-transport.md

+
+Endpoints are permitted to use other methods to detect and attempt to recover
+from interference with the handshake.  For instance, if invalid packets can be
+identified then they can be discarded.  This can be complex or difficult and so


Suggested replacement for the last two sentences: "Invalid packets may be identified and discarded using other methods, but no specific method is mandated in this document."

martinthomson

Thanks for the review. I would like another for the new text about the handshake. I took your suggestions verbatim otherwise.

martinthomson · 2018-05-23T07:06:15Z

draft-ietf-quic-transport.md

+
+As an encrypted and authenticated transport QUIC provides a range of protections
+against denial of service.  Once the cryptographic handshake is complete, QUIC
+endpoints discard packets that are not authenticated, greatly limiting the


Sure. I was hoping that we could ultimately authenticate even those packets that don't have packet protection in some way. For instance, by ensuring that the ICMP unreachable includes bytes from a packet we sent. But maybe that's stretching the definition too far.

martinthomson · 2018-05-23T07:14:38Z

draft-ietf-quic-transport.md

+These protections are not intended to be effective against an attacker that is
+able to receive QUIC packets.  Such an attacker can potentially send packets
+that will be accepted by QUIC clients or servers.  This version of QUIC only
+attempts to detect this sort of attack.  Interference with the handshake is


I've reworded this to be a little clearer (I hope). I think that it is important to say that we don't expect endpoints to do anything other than fail when an attacker tampers with the handshake. I realize that the lead-in to this paragraph didn't scope that properly though. Have another look.

MikeBishop

LGTM.

MikeBishop · 2018-05-23T16:43:49Z

draft-ietf-quic-transport.md

+use the same process for authenticating packets that they receive as they use
+after the cryptographic handshake completes.  Packets that cannot be
+authenticated are discarded.  Protecting packets in this fashion provides a
+strong assurance that the sender of the packet saw the Initial packets and


packets plural?

yeah, this should be "packet"

janaiyengar

nits, but LGTM

janaiyengar · 2018-05-23T19:50:07Z

draft-ietf-quic-transport.md

-required to match those set by a peer.  Except for an Initial packet and
-stateless reset, an endpoint only accepts packets that include a destination
+required to match those set by a peer.  Except for an Initial and stateless
+reset packets, an endpoint only accepts packets that include a destination


capitalize stateless reset

That would be a first. It's lowercase everywhere else.

janaiyengar · 2018-05-23T19:50:33Z

draft-ietf-quic-transport.md

+use the same process for authenticating packets that they receive as they use
+after the cryptographic handshake completes.  Packets that cannot be
+authenticated are discarded.  Protecting packets in this fashion provides a
+strong assurance that the sender of the packet saw the Initial packets and


yeah, this should be "packet"

janaiyengar · 2018-05-23T19:55:10Z

draft-ietf-quic-transport.md

-property that the cryptographic handshake protocol {{QUIC-TLS}} is required to
-provide, though additional validation is required for version negotiation (see
+able to receive QUIC packets prior to the connection being established.  Such an
+attacker can potentially send packets that will be accepted by QUIC clients or


s/QUIC clients or servers/the QUIC endpoints/ ?

janaiyengar · 2018-05-23T19:58:05Z

draft-ietf-quic-transport.md

+attacker can potentially send packets that will be accepted by QUIC clients or
+servers.  This version of QUIC attempts to detect this sort of attack, but it
+expects that endpoints will fail to establish a connection rather than
+recovering.  For the most part, the cryptographic handshake protocol


I think this is fine.

janaiyengar reviewed May 23, 2018

View reviewed changes

Addressing review comments, rewording handshakey bit

6cc16b6

martinthomson commented May 23, 2018

View reviewed changes

MikeBishop approved these changes May 23, 2018

View reviewed changes

janaiyengar approved these changes May 23, 2018

View reviewed changes

Fix plurals

4722286

martinthomson merged commit 88dd1c9 into master May 24, 2018

martinthomson deleted the bad-packets branch May 24, 2018 01:15

martinthomson added the -transport label Jun 27, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Write down spoofed packet guarantees #1347

Write down spoofed packet guarantees #1347

martinthomson commented May 10, 2018

janaiyengar May 23, 2018

martinthomson May 23, 2018

janaiyengar May 23, 2018

janaiyengar May 23, 2018

janaiyengar May 23, 2018

janaiyengar May 23, 2018

martinthomson May 23, 2018

janaiyengar May 23, 2018

martinthomson left a comment

martinthomson May 23, 2018

martinthomson May 23, 2018

MikeBishop left a comment

MikeBishop May 23, 2018

janaiyengar May 23, 2018

janaiyengar left a comment

janaiyengar May 23, 2018

martinthomson May 24, 2018

janaiyengar May 23, 2018

janaiyengar May 23, 2018

janaiyengar May 23, 2018

Write down spoofed packet guarantees #1347

Write down spoofed packet guarantees #1347

Conversation

martinthomson commented May 10, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martinthomson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MikeBishop left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janaiyengar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment